home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_3_06.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
76KB
|
3,366 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.LP
\fBMONTAGE: Fin de la Recommandation X.75 en\(hyt\*\|ete de cette page\fR
.sp 2P
.LP
\v'25P'
\fBRecommendation\ X.80\fR
.RT
.sp 2P
.RT
.sp 2P
.ce 1000
\fBINTERWORKING\ OF\ INTEREXCHANGE\ SIGNALLING\ SYSTEMS\fR
.EF '% Fascicle\ VIII.3\ \(em\ Rec.\ X.80''
.OF '''Fascicle\ VIII.3\ \(em\ Rec.\ X.80 %'
.ce 0
.sp 1P
.ce 1000
\fBFOR\ CIRCUIT\ SWITCHED\ DATA\ SERVICES\fR
.ce 0
.sp 1P
.ce 1000
\fI(Geneva, 1980; amended at Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.sp 2P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that Recommendations X.60 and X.71 define two different signalling systems
which are intended for use on international circuits between synchronous
data networks;
.PP
(b)
that Recommendation X.70 defines a signalling system
which is intended for use on international circuits between anisochronous
data networks;
.PP
(c)
that Administrations and RPOAs have expressed interest in implementing
Recommendations\ X.60, X.70 or\ X.71 as national signalling
systems between national data switching exchanges;
.PP
(d)
that Recommendations X.60, X.70 and X.71 have been
defined to include the necessary signals to allow interworking between any
combination of these
signalling systems
;
.PP
(e)
that there is a need to define the specific interworking requirements between
these signalling systems;
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
that interworking between any combination of signalling
systems conforming to Recommendations\ X.60, X.70 and\ X.71 should be as
defined in this Recommendation.
.bp
.sp 2P
.LP
\fB1\fR \fBGeneral\fR
.sp 1P
.RT
.sp 1P
.LP
1.1
\fIPrinciples\fR
.sp 9p
.RT
.PP
This Recommendation provides a set of interworking specifications for CCITT
circuit\(hyswitched data signalling systems. Interworking is defined as
the controlled transfer of signalling information across an interface between
different signalling systems where the significance of the transferred
information is identical, or where significance is translated in a defined
manner, and includes the performance of the appropriate interworking procedures
in association with the transfer. These interworking procedures will be
performed by an interworking function at a boundary between the
two interworking signalling systems.
.PP
Interworking commences at call set\(hyup when a link is established
between two circuits using different signalling systems and continues
throughout the call until release of the connection occurs. Interworking
ceases with the release of the connection, whether the release is initiated
by the
reception of a clear condition from either of the signalling systems involved
or by the interworking function itself in response to some abnormal
condition.
.RT
.sp 1P
.LP
1.2
\fIPresentation\fR
.sp 9p
.RT
.PP
The specifications are basically represented by flow charts
consistent with the
CCITT Specifications and Descriptions Language
(SDL)
, described in Recommendations\ Z.101 to Z.103; and are used to
describe the logical requirements of the interworking function. In addition,
two\ tables are included to show the signalling sequences required for a
typical interworking situation. Narrative description has been reduced to a
minimum.
.PP
SDL provides a method of presentation which is both comprehensive and independent
of implementation, ensuring that all interworking conditions can be covered
in a systematic manner. The logic of each signalling system is covered
in the relevant signalling Recommendations\ X.60, X.70 or\ X.71.
.RT
.sp 2P
.LP
\fB2\fR \fBInterworking procedures between Recommendations X.60\fR
\fBand\ X.71\fR
.sp 1P
.RT
.PP
The present \(sc 2 details the specific requirements for interworking between
an\ X.60 and an\ X.71 signalling system.
.PP
Table 1/X.80 illustrates the relationship between the signals on the X.60
side of the interworking function and the corresponding signals on the
X.71 side. It illustrates the simple case of a basic call which originates
in an \*QX.60 network\*U and terminates in an \*QX.71 network\*U, and which
does not
invoke any additional facilities, and it assumes that the call is successful.
The call clear\(hydown is initiated by the customer in the X.60 network.
.PP
\fR There are, however, several combinations of facilities which could
be required on a particular call which complicate the interworking procedures,
in particular the instant of connect through. In Table\ 1/X.80 the reception
of the \fICall Connected (CC)\fR signal from the Recommendation\ X.71 signalling
system defines the conclusion of the call set\(hyup sequence at the interworking
point
and hence the instant of connect through. If the call involves additional
facilities the reception of the \fITransit Through Connect (TTC)\fR signal
from the Recommendation\ X.71 signalling system initiates the additional
protocols
necessary to setting up the call successfully. Table\ 2/X.80 illustrates an
example involving these additional protocols for a call requiring both
calling and called line identities and including a positive call progress
indication.
.PP
Appendix I to this Recommendation illustrates further examples of
interworking situations which can occur for the X.60 to X.71 case. The
appendix illustrates examples of interworking situations where two \*QX.71\
networks\*U
transit an \*QX.60\ network\*U or two \*QX.60\ networks\*U transit an
\*QX.71\ network\*U.
.RT
.sp 1P
.LP
2.1
\fIInterworking from Recommendation X.60 to X.71\fR
.sp 9p
.RT
.PP
Figure 1/X.80 shows the transit exchange interworking functions
required to enable an X.60 to X.71 call to be connected.
.PP
In response to the selection information sent to the X.71 network, one
of two signals may be received: \fICC\fR or \fITTC\fR as described above.
.bp
.RT
.ce
\fBH.T. [T1.80]\fR
.ce
.line
.ce
\fBA RECUPERER PAR MONTAGE\fR
.ce
.parag
.ce
\fBH.T. [T2.80]\fR
.ce
.line
.ce
\fBA RECUPERER PAR MONTAGE\fR
.ce
.parag
.ce
\fBH.T. [T1.81]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
Terms Defined in Recommendation
_
.T&
lw(78p) | lw(78p) .
Bearer service I.230 Series
.T&
lw(78p) | lw(78p) .
Data transmission service X.10; X.300
.T&
lw(78p) | lw(78p) .
OSI network layer service X.213
.T&
lw(78p) | lw(78p) .
User class of service X.1
.T&
lw(78p) | lw(78p) .
Supplementary services I.250 Series; X.2
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/X.80 [T1.80], p.1\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T2.80]\fR
.ce
.line
.ce
\fBA RECUPERER PAR MONTAGE\fR
.ce
.parag
.ce
\fBH.T. [T1.81]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
Terms Defined in Recommendation
_
.T&
lw(78p) | lw(78p) .
Bearer service I.230 Series
.T&
lw(78p) | lw(78p) .
Data transmission service X.10; X.300
.T&
lw(78p) | lw(78p) .
OSI network layer service X.213
.T&
lw(78p) | lw(78p) .
User class of service X.1
.T&
lw(78p) | lw(78p) .
Supplementary services I.250 Series; X.2
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 2/X.80 [T2.80], p.2\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 1/X.80, (MC), p.3\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The consequent \fICall Accepted\fR \|Message(s) (CAM) which are
transmitted on the X.60 side of the interworking unit function can
contain:
.RT
.LP
a)
The \fIcall accepted\fR \|signal when a \fICC\fR \|signal was received
on the X.71 side. Note that this type of CAM (designated CAM\ 1)
can also contain the \fIcalled line identity\fR and/or a
\fIpositive call progress\fR signal for calls which have initiated
the additional protocols and are now ready to connect through.
[See\ c)
below.]
.LP
b)
The \fItransit through connect\fR \|signal when a \fITTC\fR \|signal
was received on the X.71 side. The \fITTC\fR signal may or may not
\fIrequest the calling line\fR \fIidentity\fR . The consequent \fIcall\fR
\fIaccepted\fR message (designated CAM 2) can therefore
contain:
.LP
i)
a request for the \fIcalling line identity\fR \|if it was requested and
it is not available;
.LP
ii)
no request if the calling line identity
is already available as part of the \fIoriginating address\fR message;
.LP
iii)
no request if the \fIcalling line\fR \fIidentity\fR \|was not requested.
.LP
In i) a \fIcalling line identity\fR \|message is received from
the X.60 side in response to the CAM\ 2. Then the \fIcalling line identity\fR
can be transmitted on the X.71 side.
.LP
In ii) the \fIcalling line identity\fR \|can be transmitted on
the X.71 side.
.LP
In iii) a Transit centres Through\(hyConnected (TTD) signal is transmitted
on the X.71 side.
.LP
c)
A \fIpositive call progress\fR \|signal and/or the \fIcalled line\fR
\fIidentity\fR \|when they were received on the X.71 side preceding
the \fIcall connected (CC)\fR signal. This information can be
included in the CAM\ 1 sent on the X.60 side to complete the
through\(hyconnection.
.sp 1P
.LP
2.2
\fIInterworking from Recommendation X.71 to X.60\fR
.sp 9p
.RT
.PP
Figure 2/X.80 shows the transit exchange interworking functions
required to enable an X.71 to X.60 call to be connected.
.PP
The signals that can be transmitted on the X.71 side of the
interworking unit function in response to a CAM\ 1 or CAM\ 2 message are as
follows:
.RT
.LP
a)
The \fIcall connected (CC)\fR \|signal either directly or after the transmission
of \fIcalled\fR \|and/or \fIcalling line identification\fR
and/or a \fIpositive call progress\fR signal.
.LP
b)
If the CAM 1 or CAM 2 contains a \fIrequest for calling line\fR \fIidentity\fR
, a \fITTC\fR signal is transmitted with a request for \fIcalling line\fR
\fIidentification\fR on the X.71 side. In response, the \fIcalling line
identity\fR is received from the X.71 side and a \fIcalling line identity
message\fR transmitted on the X.60 side.
.LP
\fINote\fR \ \(em\ If the \fIcalling line identity\fR \|is sent as a
result of a CAM\ 2 request, a subsequent CAM\ 1, which may contain the
\fIcalled line identity\fR , must be sent on the X.60
side in order to complete the call set\(hyup.
.LP
c)
Where \fIcalling line identity\fR \|is not required by a CAM\ 2, a \fITTC\fR
\|signal is sent on the X.71 side. A \fITTD\fR signal will be received
in
response and this may be received before or after a CAM\ 1, which may contain
the \fIcalled line identity\fR , has been received from the X.60 side in
order to
complete the call.
.LP
d)
In b) and c) a \fIpositive call progress\fR \|signal and/or the \fIcalled
line identity\fR \|can be sent on the X.71 side before the \fICC\fR signal.
.LP
e)
Where a CAM 1 is received without a \fIrequest for calling\fR \fIline
identity\fR \|but including the \fIcalled line identity\fR or a \fIpositive
call\fR \fIprogress\fR signal, a \fITTC\fR signal is sent on the X.71 side.
When a \fITTD\fR
signal has been received in response, the \fIcalled line identity\fR and/or the
\fIpositive call progress\fR signal may be sent before the \fICC\fR signal.
.sp 1P
.LP
2.3
\fICall clear\(hydown\fR
.sp 9p
.RT
.PP
A \fIcall clear\(hydown\fR \|signal can originate in either the X.60 or
X.71 network. The interworking function must therefore be capable of detecting
\fIclear\fR signals and messages, which can occur at any time during the
call
set\(hyup or data phase of a call, and take the appropriate action as detailed
below:
.RT
.LP
a)
\fIA\fR clear request \fIsignal received from the X.71 network\fR
.LP
This will initiate disconnection of the call at the
interworking function, the transmission of a \fIclear confirmation\fR signal
to the X.71 network and a \fIclear\fR message to the
X.60 network. At this point interworking ceases
and each network clears down according to the normal
X.60 or X.71 procedures.
.bp
.LP
b)
\fIA\fR clear message \fIreceived from the X.60 network\fR
.LP
This will initiate disconnection of the call at the
interworking function, the transmission of a \fIclear\fR message to the X.60
network and a \fIclear request\fR signal to the X.71 network. At
this point interworking ceases and each network clears down
according to the normal X.60 or X.71 procedures.
.LP
\fINote\fR \ \(em\ The interworking function may optionally detect the
internetwork data circuit \fIclear request\fR signal initiated by
the user in the X.60 network. This will cause the disconnection
of the call at the interworking function and initiate the same
procedures as described above.
.sp 1P
.LP
2.4
\fICall failure conditions during call set\(hyup\fR
.sp 9p
.RT
.PP
Supervision of time\(hyouts during call set\(hyup takes place as stated
in the signalling Recommendations\ X.71 and\ X.60 respectively.
.PP
The expiry of such a supervisory\(hytimer will lead to normal clearing
as shown in Figures\ 1/X.80 and\ 2/X.80.
.RT
.sp 2P
.LP
\fB3\fR \fBInterworking procedures between Recommendations X.70 and X.71\fR
.sp 1P
.RT
.PP
Since the proposals for Recommendations\ X.70 and X.71 are closely related,
interworking between an X.70 and an X.71 network should be
straightforward; however the interworking procedures required are for further
study.
.RT
.sp 2P
.LP
\fB4\fR \fBInterworking procedures between Recommendations\ X.60 and X.70\fR
.sp 1P
.RT
.PP
The required interworking procedures should be similar to the
Recommendation\ X.60/71 case; however they are for further study.
.RT
.LP
.rs
.sp 25P
.ad r
\fBBlanc\fR
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2/X.80, (MC), p.4\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation X.80)
.sp 9p
.RT
.ce 0
.ce 1000
\fB
\fBInterworking cases, Recommendations X.60/X.71\fR \v'4P'
.sp 1P
.RT
.ce 0
.PP
The following sequence charts illustrate examples of complex transit interworking
situations.
\v'2P'
.sp 1P
.RT
.sp 2P
.LP
\fIKey to sequence charts\fR
.sp 1P
.RT
.sp 1P
.LP
O
\ \(em\ Originating network
.sp 9p
.RT
.LP
T
\ \(em\ Transit network
.LP
D\ \(em\ Destination network
.LP
X
\ \(em\ Data path through\(hyconnect
\v'2P'
.sp 2P
.LP
\fIRecommendation X.60\fR
.sp 1P
.RT
.sp 1P
.LP
AM
\(em
Address message
.sp 9p
.RT
.LP
AM\ (CLI)
\(em
Address message with calling line identity
(CLI)
.LP
AM\ (CDIR)
\(em
Address message with request for called line
identity (CDI)
.LP
AM\ (CLI\ +\ CDIR)
\(em
Address message with CLI and request for CDI
.LP
CAM\ 1
\(em
Call accepted message contains call accepted
signal; can contain CDI, CLI request and/or
positive call progress signal
.LP
CAM\ 2
\(em
Call accepted message; TTC signal can contain
CLI request
.LP
CLIM
\(em
Calling line identity message
\v'2P'
.sp 2P
.LP
\fIRecommendation X.71\fR
.sp 1P
.RT
.sp 1P
.LP
CS
\(em
Calling signal
.sp 9p
.RT
.LP
SS
\(em
Selection signals; can include request for
called line identity
.LP
C.CONF
\(em
Call confirmation signal
.LP
CC
\(em
Call connected signal
.LP
TTC
\(em
Transit through\(hyconnect signal can include
request for Calling Line Identity
.LP
TTD
\(em
Transit centres through\(hyconnected signal
.LP
CLI
\(em
Calling line identity
.LP
CDI
\(em
Called line identity
.LP
CP+
\(em
Positive call progress signal
.bp
.sp 2P
.LP
I.1
\fIInterworking, Recommendations X.60/X.71/X.60\fR
.sp 1P
.RT
.sp 1P
.LP
a)
\fICalled line identity and/or positive call progress signal\fR
\fIrequired, calling line identity not required\fR
.sp 9p
.RT
.LP
.rs
.sp 12P
.ad r
\fBFigure CCITT\(hy34820, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
b)
\fIBoth called and calling line identity required and/or positive\fR
\fIcall progress signal\fR
.sp 9p
.RT
.LP
.rs
.sp 15P
.ad r
\fBFigure CCITT\(hy34830, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure CCITT\(hy34840, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
I.2
\fIInterworking, Recommendations X.71/X.60/X.71\fR
.sp 1P
.RT
.sp 1P
.LP
a)
\fICalled line identity and/or positive call progress signal,\fR
\fIcalling identity not required\fR
.sp 9p
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure CCITT\(hy34850, (M), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
b)
\fICalling line identity and called line identity and/or positive\fR
\fIcall progress signal required\fR
.sp 9p
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure CCITT\(hy34860, (M), p.9\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 4P
.ad r
\fBBlanc\fR
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fBRecommendation\ X.81\fR
.RT
.sp 2P
.ce 1000
\fBINTERWORKING\ BETWEEN\ AN\ ISDN\ CIRCUIT\(hySWITCHED\ AND\ A\ CIRCUIT\(hySWITCHED\fR
.EF '% Fascicle\ VIII.3\ \(em\ Rec.\ X.81''
.OF '''Fascicle\ VIII.3\ \(em\ Rec.\ X.81 %'
.ce 0
.sp 1P
.ce 1000
\fBPUBLIC\ DATA\ NETWORK\ (CSPDN)\fR
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that I\(hySeries Recommendations describe the integrated
services digital network (ISDN);
.PP
(b)
that interface characteristics, line multiplexing and
inter\(hyexchange signalling for use in CSPDNs are described by Recommendations
such as\ X.26/X.27/X.50/X.51/Q.761 to Q.766/X.60/X.61/X.71/X.80;
.PP
(c)
that Recommendation X.200 describes the reference model for Open System
Interconnection;
.PP
(d)
that Recommendation X.213 describes the Network Service Definition for
Open Systems Interconnection for CCITT applications;
.PP
(e)
that Recommendation X.300 defines the general
principles for interworking between public networks, and between public
networks and other networks for the provision of data transmission services;
.PP
(
f
)
that Recommendation X.301 defines the
general arrangements for call control within a subnetwork and between
subnetworks for the provision of data transmission services;
.PP
(g)
that Recommendation X.302 defines the general
arrangements for internal network utilities within a subnetwork and between
subnetworks for the provision of data transmission services;
.PP
(h)
that Recommendation X.305 describes functionalities of subnetworks relating
to the support of the\ OSI Network Service;
.PP
(i)
that Recommendation X.10 describes categories of access to PSPDNs and\
ISDNs for the provision of data transmission services;
.PP
(j)
that the I.230 Series Recommendations describe
the bearer services supported by an\ ISDN;
.PP
(k)
that Recommendation X.30 describes the support of
X.21, X.21\|\fIbis\fR and\ X.20\|\fIbis\fR based\ DTEs on the\ ISDN;
.PP
(l)
the need for arrangements when interworking between
ISDN circuit switched and CSPDNs for the provision of data transmission
services.
.sp 1P
.LP
\fIunanimously declares the view\fR
.sp 9p
.RT
.PP
that the scope of this Recommendation is intended to cover
interworking between an\ ISDN using circuit\(hyswitched connection types and
a CSPDN.
.sp 1P
.ce 1000
CONTENTS
.ce 0
.sp 1P
.sp 2P
.LP
0
\fIIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
1
\fIScope and field of application\fR
.sp 9p
.RT
.sp 1P
.LP
2
\fIReferences\fR
.sp 9p
.RT
.sp 1P
.LP
3
\fIDefinitions\fR
.sp 9p
.RT
.sp 1P
.LP
4
\fIAbbreviations\fR
.sp 9p
.RT
.sp 1P
.LP
5
\fIGeneral aspects\fR
.sp 9p
.RT
.LP
5.1
CSPDN
.LP
5.2
ISDN (CS)
.LP
5.3
Call control between the CSPDN and ISDN
.bp
.sp 1P
.LP
6
\fISpecification of interworking functions\fR
.sp 9p
.RT
.LP
6.1
Interworking functions for identical data transmission
services
.LP
6.1.1
Physical link characteristics and interworking
functions assigned to layer\ 1
.LP
6.1.2
Support of the OSI\(hyNLS
.LP
6.1.3
Signalling conversion (protocol mapping)
.LP
6.1.4
Protocol mapping for supplementary services
.LP
6.1.5
Mapping of service signals and causes
.LP
6.2
Interworking functions for non\(hyidentical data transmission
services
.LP
6.2.1
Physical link characteristics and interworking
functions assigned to layer\ 1
.LP
6.2.2
Support of the OSI\(hyNLS
.LP
6.2.3
Signalling conversion (protocol mapping)
.LP
6.2.4
Protocol mapping for supplementary services
.LP
6.2.5
Mapping of service signals and causes
.sp 1P
.LP
7
\fIOperation and maintenance\fR
.sp 9p
.RT
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation is one of a set of Recommendations produced to facilitate
considerations of interworking between networks. It is based on
Recommendation\ X.300, which defines the general principles for interworking
between public networks, and between public networks and other networks
for the provision of data transmission services. Recommendation\ X.300
indicates in
particular how collections of physical equipment can be represented as
\*QSubnetworks\*U for consideration in interworking situations.
.PP
This Recommendation describes the interworking arrangements between
ISDNs (circuit switched bearer) and CSPDNs for the provision of data
transmission services.
.RT
.sp 2P
.LP
\fB1\fR \fBScope and field of application\fR
.sp 1P
.RT
.PP
The purpose of this Recommendation is to describe the detailed
arrangements for the interworking between CSPDNs and ISDNs (CS) for the
provision of data transmission services. These arrangements are applicable
only to the interworking involving transmission capabilities, and not to
interworking involving communication capabilities as described in
Recommendation\ X.300.
.RT
.LP
a)
within the scope of interworking between an ISDN using
circuit\(hyswitched connection types and a CSPDN the following
cases of network interworking can be identified:
.LP
i)
where the terminals connected to the interworking
networks use identical data transmission services and
have identical high layer capabilities. The identity
of data transmission services in both networks
assumes that both terminals involved in a
communication belong to the same user class of
service;
.LP
ii)
where the terminals connected to the interworking
networks use non\(hyidentical data transmission services
but have identical high layer capabilities. In this
case two terminals involved in a communication may
belong to different user classes of service, e.g. user
classes of service\ 4 and\ 30.
.LP
b)
Not within the scope of this Recommendation is asynchronous mode of operation
at the network\(hyto\(hynetwork interface (ISDN\(hyto\(hyCSPDN
interface). In the case, that the\ ISDN supports the connection of asynchronous
mode terminals via an appropriate terminal adaptor (TA) (see
Recommendation\ X.30) and that interworking has to be provided to asynchronous
terminals connected to a CSPDN, then the interworking arrangements as for
synchronous mode operation will be used. Asynchronous to synchronous conversion
may be provided within the\ TA for ISDN\(hyconnected terminals and at the
terminal or at the CSPDN for CSPDN\(hyconnected terminals.
.LP
\fINote\fR \ \(em\ The typing of subnetworks in this Recommendation is
based on the support for the OSI connection\(hymode Network Service and
is
therefore only valid in this context.
.bp
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.sp 1P
.LP
[1]
Recommendation X.1
.sp 9p
.RT
.LP
[2]
Recommendation X.2
.LP
[3]
Recommendation X.10
.LP
[4]
Recommendation X.20
.LP
[5]
Recommendation X.21
.LP
[6]
Recommendation X.21\|\fIbis\fR
.LP
[7]
Recommendation X.25
.LP
[8]
Recommendation X.27
.LP
[9]
Recommendation X.30
.LP
[10]
Recommendation X.50
.LP
[11]
Recommendation X.51
.LP
[12]
Recommendation X.60
.LP
[13]
Recommendation X.61
.LP
[14]
Recommendation X.71
.LP
[15]
Recommendation X.300
.LP
[16]
Recommendation X.321
.LP
[17]
I.230 and I.250 Series Recommendations
.LP
[18]
Recommendation G.703
.LP
[19]
Recommendation G.708
.LP
[20]
Recommendation G.811
.LP
[21]
Recommendation Q.761\(hyQ.766
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.PP
This Recommendation makes use of the folowing terms defined in the Recommendation
as indicated:
.RT
.ce
\fBH.T. [T1.81]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
Terms Defined in Recommendation
_
.T&
lw(78p) | lw(78p) .
Bearer service I.230 Series
.T&
lw(78p) | lw(78p) .
Data transmission service X.10; X.300
.T&
lw(78p) | lw(78p) .
OSI network layer service X.213
.T&
lw(78p) | lw(78p) .
User class of service X.1
.T&
lw(78p) | lw(78p) .
Supplementary services I.250 Series; X.2
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du point 3 [T1.81], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB4\fR \fBAbbreviations\fR
.sp 1P
.RT
.sp 1P
.LP
DTE
Data terminal equipment
.sp 9p
.RT
.LP
DCE
Data circuit\(hyterminating equipment
.LP
SS\ No.7
Common channel signalling system number 7
.LP
CSPDN
Circuit switched public data network
.LP
ISDN
Integrated services digital network
.LP
IWF
Interworking functions
.LP
LAPB
Link access protocol, balanced
.LP
OSI\(hyNLS
Open system interconnection \(em Network layer service
.LP
HDLC
High level data link control
.LP
TA
Terminal adaptor
.LP
TE
Terminal equipment
.LP
UC
User class of service
.bp
.LP
\fIAbbreviations of SS No. 7 messages and X.71 signals\fR
.sp 1P
.RT
.sp 2P
.LP
\fISS No. 7 messages:\fR
.sp 1P
.RT
.sp 1P
.LP
ACM
Address complete
.sp 9p
.RT
.LP
ANS
Answer
.LP
IAM
Initial address
.LP
INF
Information
.LP
INR
Information message
.LP
REL
Release
.LP
RLC
Release complete
.LP
RLSD
Released
.sp 2P
.LP
\fIX.71 signals:\fR
.sp 1P
.RT
.sp 1P
.LP
CC
Call connected
.sp 9p
.RT
.LP
CCF
Call confirmation
.LP
CDI
Called line identification
.LP
CLI
Calling line identification
.LP
CLEAR
Clearing signal
.LP
CLEAR C.
Clear confirmatiom
.LP
SEL
Selection signals
.LP
TTC
Transit through connect
.sp 2P
.LP
\fIAdditional information contained in SS No. 7 messages and X.71\fR
\fIsignals\fR
.sp 1P
.RT
.sp 1P
.LP
CDI
Called line identification
.sp 9p
.RT
.LP
CDIR
Called line identification request
.LP
CLI
Calling line identification
.LP
CLIR
Calling line identification request
.sp 2P
.LP
\fB5\fR \fBGeneral aspects\fR
.sp 1P
.RT
.PP
This Recommendation, in describing interworking arrangements
between two subnetworks for the provision of data transmission services,
adheres to the general principles of Recommendation\ X.300. The environments
of these two subnetworks are described in the following sections.
.RT
.sp 1P
.LP
5.1
\fICSPDN\fR
.sp 9p
.RT
.PP
The CSPDN provides circuit switched data transmission services as defined
in Recommendations\ X.1 and\ X.2 for the provision of data transmission
services, the CSPDN may be accessed by\ DTEs by the categories of access\
B as
defined in Recommendation\ X.10. Other possibilities of access, which are not
relevant to this Recommendation are described in
Recommendation\ X.321.
.RT
.sp 1P
.LP
5.2
\fIISDN\fR
.sp 9p
.RT
.PP
The ISDN provides circuit switched data transmission
services/bearer services/supplementary services as defined in
Recommendation\ X.1, the I.230 Series and\ I.250 Series. For the provision of
data transmission services the\ ISDN may be accessed by\ TE2s by the categories
of access\ S as defined in Recommendation\ X.10 and by\ TEs as defined
in the
I.230 Series. (circuit\(hymode 64\ kbit/s unrestricted, unstructured). Other
possibilities of access which are not relevant to this Recommendation are
described in Recommendation\ X.321.
.bp
.RT
.sp 1P
.LP
5.3
\fICall control between the CSPDN and ISDN\fR
.sp 9p
.RT
.PP
The general arrangements for call control between the CSPDN and
ISDN circuit switched are as defined in Recommendation\ X.301. Network
utililities used between the CSPDN and\ ISDN circuit switched are as defined
in Recommendation\ X.302 (not visible for users).
.RT
.sp 2P
.LP
\fB6\fR \fBSpecification of interworking functions\fR
.sp 1P
.RT
.PP
The interworking functions specified hereafter have been grouped
in accordance with their assignment to OSI\(hymodel\(hylayers\ 1 to\ 3.
.RT
.sp 1P
.LP
6.1
\fIInterworking functions for identical data transmission\fR
\fIservices\fR
.sp 9p
.RT
.PP
Reference configuration of the interworking between a circuit
switched\ ISDN and a CSPDN using identical bearer services.
.PP
As can be seen from Figure 1/X.81, the following terminal to terminal interworking
cases may arise for which network interworking capabilities are
necessary for user classes\ 3\(hy7/categories\ S and\ B of
Recommendation\ X.10.
.RT
.LP
ISDN
CSPDN
.LP
(Categories S1\(hyS5)
(Categories B1\(hyB5)
.LP
TE2 + TA X.21
DTE X.21
.LP
TE2 + TA X.21
DTE X.21\|\fIbis\fR
.LP
TE2 + TA X.21\|\fIbis\fR DTE X.21
.LP
TE2 + TA X.21\|\fIbis\fR DTE X.21\|\fIbis\fR
.LP
TE1 (see Note in Figure 1/X.81)
.PP
TE2 and DTE involved in an end\(hyto\(hyend communication must be of
the same user class. In this case a CSPDN Gateway must also support the same
user class of service.
.LP
.rs
.sp 23P
.ad r
\fBFigure 1/X.81, (N), p.11\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
6.1.1
\fIPhysical link characteristics and interworking functions\fR
\fIassigned to layer\ 1\fR
.sp 1P
.RT
.sp 1P
.LP
6.1.1.1
\fILocation of the interworking functions\fR
.sp 9p
.RT
.PP
The interworking functions may be provided by the ISDN, or by the CSPDN
or separately between the interworking networks.
.PP
The interworking links may be provided as multiplexed lines offering a
multiplicity of channels at the conversion point or as individual channels.
Consequently, the conversion facility has to provide layer\ 1
multiplexing/demultiplexing functions in the case where multiplexed lines
are connected to it. Multiplexing may take place only on the\ ISDN side
or only on the CSPDN side or on both sides of the location, where the interworking
functions are provided. The question as to whether the interconnection lines
will be multiplexed or not will depend on the location of the\ IWF, i.e. on
whether the conversion facilities are installed at the data switching exchange
.PP
or at the\ ISDN exchange. In either case the location of the\ IWF should be
considered from an economic viewpoint regardless of whether the conversion
facilities are designed as separate hardware and software\(hybased modules
or as integrated parts of either an\ ISDN exchange or a data switching
exchange
(see also Figure\ 2/X.81).
.RT
.LP
.rs
.sp 39P
.ad r
\fBFigure 2/X.81, (N), p.12\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
Depending on the location of the IWF (see Figure 2/X.81), the
electrical characteristics on one or both sides of the\ IWF shall comply with
the current Recommendations on interface characteristics as follows:
.LP
a)
Recommendation G.703/G.708 when offering the 2048/1544
kbit/s interface for 32/24\ \(mu\ 64\ kbit/s channels on the\ ISDN
side;
.LP
b)
Recommendation G.703/X.27 when offering the 64 kbit/s
interface for data channels multiplexed in accordance with
the\ X.50 or the\ X.51 or the\ X.51 multiplex scheme on the
CSPDN side;
.LP
c)
any interface recommendation applicable to individual data
channels offered on the CSPDN side at speeds specified for
user classes of service\ 3\(hy7 and their associated 6\ +\ 2 and
8\ +\ 2 envelope bit rates.
.sp 1P
.LP
6.1.1.2
\fITiming requirements\fR
.sp 9p
.RT
.PP
Since interworking takes place between two networks, the ISDN and the CSPDN,
phase and/or clock adjustment must take place. The timing
requirements of the\ IWF are the same, as specified in Recommendation\
G.811 for the interconnection of digital link.
.RT
.sp 1P
.LP
6.1.1.3
\fIBit rate adaption\fR
.sp 9p
.RT
.PP
Since switching in the ISDN is provided only for 64 kbit/s channels and
no standards are currently available for switching of subchannels, the
bit rates of user classes of service\ 3\(hy7 have to be adapted to 64\
kbit/s.
.PP
The bit rate adaption mechanism shall be in accordance with
Recommendation\ X.30, \(sc\(sc\ 2.1.1 and\ 2.2.1. On the CSPDN side of
the\ IWF there
will be the need to allocate the information which is contained within
40\ bit frames received from the\ ISDN on a 64\ kbit/s bearer into either
6\ +\ 2 or 8\ +\ 2 envelopes.
.PP
The same applies to an incoming envelope stream received from a data network.
The bit positions within the envelopes have to be allocated to the
relevant positions in an outgoing 40\ bit frame to be sent to the\ ISDN.
.PP
Concerning the layer 1 relay functions of an IWF for rate adaption,
the following two configurations, presented by Figure\ 3/X.81, have been
identified.
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 3/X.81, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
The bit rate adaption for both directions is restricted to the
transfer of information and status. Framing bits, housekeeping bits and any
other bits will not be transferred by the\ IWF. Mapping of housekeeping
functions is a subject of further study.
.LP
(1)
Interworking with an X.50\(hystructured CSPDN
.LP
(8 bit envelope structure)
.LP
For interworking with a CSPDN utilizing the 8 bit envelope structure
as identified in Recommendation\ X.50, \(sc\ 1.1\ a). This implies the
suppression of each fourth status bit on transition from CSPDN to ISDN and
replication of each third status bit on transition from ISDN to CSPDN is
necessary.
.bp
.LP
(2)
Interworking with an X.51\(hystructured CSPDN
.LP
(10 bit envelope structure)
.LP
For interworking with a CSPDN utilising the 10 bit envelope
structure as identified in Recommendation\ X.51, the data and status bits are
mutually assembled for retransmission in the coordination defined in\ X.51
respectively\ X.30. An example is shown in Figure\ 4/X.81.
.LP
.rs
.sp 23P
.ad r
\fBFigure 4/X.81, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.1.2
\fISupport of the OSI\(hynetwork layer service (OSI\(hyNLS)\fR
.sp 9p
.RT
.PP
The support of the OSI\(hyNLS provided by the interworking
networks is shown in Figure\ 5/X.81 which is in accordance with
Recommendation\ X.321.
.PP
Mapping of OSI\(hyNLS \(em signals by the IWF for the call establishment
phase is for further study.
.PP
\fINote\fR \ \(em\ Since the CSPDN is not capable of giving full support to
the OSI\(hyNLS during the call establishement phase, the\ IWF have to react on
requests, which may arise at the ISDN\(hyside and which cannot be handled
successfully within the CSPDN.
.RT
.sp 1P
.LP
6.1.3
\fISignalling conversion (protocol mapping)\fR
.sp 9p
.RT
.PP
While on the ISDN side of the IWF common channel signalling with
the SS\ No.\ 7 ISDN USER PART can always be assumed, signalling on the data
network side can be either channel associated utilizing the\ X.71 signalling
scheme or SS\ No.\ 7 based on\ X.60 and X.\ 61 or\ Q.761 to\ Q.766.
.PP
The logical representation of the mapping functions in the case of
signalling conversion from SS\ No.\ 7 to\ X.71 is shown in Figure\ 6/X.81 and
\(sc\ 6.1.3.1 to\ 6.1.3.3. A typical configuration of an end\(hyto\(hyend
data connection including several signalling conversion points is shown
in
Figure\ 7/X.81.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 5/X.81, (N), p.15\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 24P
.ad r
\fBFigure 6/X.81, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 17P
.ad r
\fBFigure 7/X.81, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.1.3.1
\fISignalling conversion for a basic call from ISDN to CSPDN\fR
.sp 9p
.RT
.PP
Figure 8/X.81 illustrates the signalling conversion procedure in
the IWF referring to the simple case of a basic call which originates in
an\ ISDN and terminates in an\ X.71 network, and which does not invoke any
additional facilities. The call is assumed to be successful and the clear
down is initiated by the user of the\ ISDN. Besides of the signalling conversion
functions in the\ IWF Figure\ 8/X.81 also shows the relevant signalling
events of the D\(hychannel protocol and of Recommendation\ X.21.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 8/X.81, (N), p.18\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The call set\(hyup sequence begins in the IWF at the moment when the SS\
No.7 initial address message (IAM)
.FS
Containing all information for call set\(hyup.
.FE
is received from the adjacent\ ISDN exchange. At this point of time the
64\ kbit/s communication channel is already through\(hyconnected within
the\ ISDN. In the following the\ X.71 call signal and selection signals
(SEL) are sent to the adjacent CSPDN exchange, which confirms the call
with the call
confirmation signal (CCF). The call is forwarded link by link to the
destination exchange of the CSPDN which calls according to Recommendation\
X.21 the\ DTE. After the\ DTE has accepted the call the destination exchange
of the
CSPDN sends back the\ X.71 call connected signal\ (CC). The CC\ signal is
transmitted link by link towards the\ IWF. Parallel with the link by link
transmission of the\ CC signal the data channel is switched through within
the CSPDN. The reception of the CC\ signal and of the terminating throughconnection
signal (1,\ ON) which is sent across the throughconnected data channel
by the
called\ DTE defines the instant of connect through in the\ IWF.
.PP
The IWF sends instead of the CC signal the SS\ No.\ 7 address complete
message (ACM). After the data channel through\(hyconnection within the
IWF the
SS\ No.\ 7 answer message (ANS) is sent to the adjacent ISDN exchange. Both
messages are transmitted link by link towards the originating exchange of
the ISDN. The originating exchange of the ISDN sends after reception of
ANS the CONNECT message (according to Recommendation\ Q.931) to the terminal
adaptor\ (TA) of the calling\ TE2, and as a consequence throughconnection
of the data channel in the\ TA can be performed according to Recommendation\
X.30. Now ready for data alignment followed by data transfer can take place
between TE2 and DTE according to Recommendation\ X.21.
.PP
Clearing is initiated for example at the TE2 by DTE clear request (0, OFF),
which is transmitted transparently via the data channel to the\ DTE.
Accompanying this inslot signal the\ TA sends the DISCONNECT message (according
to Recommendation\ Q.931) to the originating ISDN exchange. From there
the
No.\ 7 RELEASE message is transmitted link by link towards the IWF and as a
consequence the 64\ kbit/s communication channel is cleared down. The clearing
down of the data channel within the CSPDN is initiated by the reception
of the clearing signal (0,\ OFF).
.RT
.sp 1P
.LP
6.1.3.2
\fISignalling conversion for a basic call from CSPDN to ISDN\fR
.sp 9p
.RT
.PP
Figure 9/X.81 illustrates the signalling conversion procedure in
the IWF referring to the simple case of a basic call which originates in a
CSPDN and terminates in an\ ISDN, and which does not invoke any additional
facilities. The call is assumed to be successful and the clear down is
initiated by the customer of the CSPDN. After throughconnection of the
64\ kbit/s communication channel in the ISDN exchanges the SS\ No.\ 7 ANS
message is received in the IWF. As a consequence the IWF sends the X.71
CC\ signal to the adjacent CSPDN exchange. The CC\ signal is transmitted
link by link towards the originating exchange of the CSPDN. By this way
the data
channel is switched through within the CSPDN.
.PP
After the data channel finally is switched through in the originating exchange
of the CSPDN and in the terminal adaptor ready for data alignment
between\ DTE and\ TE2 can be performed.
.RT
.sp 1P
.LP
6.1.3.3
\fISignalling conversion for a complex call set\(hyup between ISDN\fR
\fIand CSPDN\fR
.sp 9p
.RT
.PP
If the call involves additional facilities in comparison with the basic
call additional procedures are necessary in Recommendation\ Q.761 to\ 765
and in Recommendation\ X.71.
.PP
Figures 10/X.81 and 11/X.81 illustrate examples involving these
additional procedures for call set\(hyup requiring both calling and called line
identification.
.RT
.sp 1P
.LP
6.1.3.3.1
\fICall set\(hyup from ISDN to CSPDN\fR \| (Figure 10/X.81)
.sp 9p
.RT
.PP
In this case the called line identification (CDI) is requested by means
of an additional information (CDIR) within the X.71 selection signals
(SEL). The request of calling line identification (CLIR) is contained in
the X.71 Transit through connect signal (TTC) and in the SS\ No.\ 7 information
message\ (INR).
.PP
The called line identification (CDI) is transmitted via the CSPDN as a
separate X.71 signal and via the ISDN as an additional information of the
address complete message (ACM).
.PP
The calling line identification (CLI) is transmitted via the ISDN by means
of the information message (INF) and via the CSPDN as a separate\ X.71
signal.
.PP
If the calling line identification (CLI) is already contained in the SS\
No.\ 7 IAM independently if it is requested or not, the SS\ No.\ 7 messages
INR and INF may be omitted.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 9/X.81, (N), p.19\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 22P
.ad r
\fBFigure 10/X.81, (N), p.20\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.1.3.3.2
\fICall set\(hyup from CSPDN to ISDN\fR \| (Figure 11/X.81)
.sp 9p
.RT
.PP
Calling and called line identification and their requests are
carried within the same SS\ No.\ 7 message and\ X.71 signals as described
under \(sc\ 6.1.3.3.1.
.RT
.LP
.rs
.sp 22P
.ad r
\fBFigure 11/X.81, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
6.1.3.4
\fIReady for data alignment\fR
.sp 9p
.RT
.PP
For user classes 3\(hy7 a ready for data alignment procedure is
executed after end\(hyto\(hyend connection has been established. The purpose
of the ready for data alignment procedure is to indicate to the communicating
terminals the exact point in time of the entry into the data transfer phase.
The ready for data alignment signal is defined by the reception of a
1/ON\(hysignal at the user/network interfaces at both ends. The 1/ON\(hysignal
is
transmitted:
.RT
.LP
\(em
in the ISDN by setting the data bits of the X.30\(hyframes to
one and the associated status bits to ON,
.LP
\(em
in the CSPDN by setting the data bits of the envelopes to one and the
associated status bits to ON.
.PP
For the ready for data alignment signal the IWF are
transparent.
.sp 1P
.LP
6.1.4
\fIProtocol mapping for supplementary services\fR
.sp 9p
.RT
.PP
The IWF shall map the protocols which are necessary to support
supplementary services. Bearing in mind, that for each network, the\ ISDN as
well as for the CSPDN an individual set of supplementary services is defined,
three different situations of interworking will arise:
.RT
.LP
a)
A specific supplementary service is supported by both
networks equivalently. In this case a one to one mapping by the\ IWF is
possible.
.LP
b)
A specific supplementary service is supported by the ISDN
but not supported equivalently by the CSPDN. In this case;
.LP
\(em
either the request for this service coming from the
ISDN has to be refused by the\ IWF, or
.LP
\(em
the request for this service coming from the ISDN may be mapped to the
CSPDN but with reduced functionality.
.LP
c)
A specific supplementary service is supported by the CSPDN but not supported
equivalently by the\ ISDN. In this case;
.LP
\(em
either the request for this service coming from the
CSPDN has to be refused by the\ IWF, or
.LP
\(em
the request for this service coming from the CSPDN may be mapped to the\
ISDN but with reduced functionality.
.PP
A table containing the supplementary services supported by CSPDN as specified
in Recommendation\ X.2 is given in Table\ 1/X.81. The supplementary services
for data transmission supported by ISDN circuit switched are specified
in the I.250\ Series Recommendations.
.sp 1P
.LP
6.1.5
\fIMapping of service signals and causes\fR
.sp 9p
.RT
.PP
The IWF shall map signals and causes used in each of the
interworking networks. Bearing in mind, that the list of causes used in
the\ ISDN and list of service signals used in the CSPDN are not fully identical,
a complete one to one mapping of all signals is not possible.
.PP
A table containing the service signals of the CSPDN and the causes of the\
ISDN and their mapping is for further study.
.RT
.sp 1P
.LP
6.2
\fIInterworking functions for non\(hyidentical data transmission\fR
\fIservices\fR
.sp 9p
.RT
.PP
Reference configuration of the interworking between a
circuit\(hyswitched\ ISDN and a CSPDN using different data transmission
services:
.PP
In Figure 12/X.81 end\(hyto\(hyend communication between terminals to
different user classes of service is assumed. As an example, TE1\ may belong
to user class of service\ 30 at a data signalling rate of 64\ kbit/s and
the\ DTE may belong to user class of service\ 4 at a data signalling rate
of 2400\ bit/s
category\ B2. The interworking functions in Figure\ 12/X.81 are partly
different from those in Figure\ 1/X.81.
.RT
.sp 2P
.LP
6.2.1
\fIPhysical link characteristics and interworking functions\fR
\fIassigned to layer\ 1\fR
.sp 1P
.RT
.sp 1P
.LP
6.2.1.1
\fILocation of the interworking functions\fR
.sp 9p
.RT
.PP
Location and features of the interworking functions are the same as described
in \(sc\ 6.1.1.1 for the cases where the data transmission services are
identical.
.bp
.RT
.ce
\fBH.T. [T2.81]\fR
.ce
TABLE\ 1/X.81
.ce
\fBSupplementary services supported by CSPDN\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(18p) | lw(120p) .
1\fB.\ \ \fR T{
Optional user facilities assigned for an agreed contractual
period
T}
.T&
cw(18p) | lw(120p) .
1.1\ Direct call
.T&
cw(18p) | lw(120p) .
1.2\ Closed user group
.T&
cw(18p) | lw(120p) .
1.3\ T{
Closed user group with outgoing access
T}
.T&
cw(18p) | lw(120p) .
1.4\ T{
Closed user group with incoming access
T}
.T&
cw(18p) | lw(120p) .
1.5\ T{
Incoming calls barred within a closed user group
T}
.T&
cw(18p) | lw(120p) .
1.6\ T{
Outgoing calls barred within a closed user group
T}
.T&
cw(18p) | lw(120p) .
1.7\ Calling line identification
.T&
cw(18p) | lw(120p) .
1.8\ Called line identification
.T&
cw(18p) | lw(120p) .
1.9\ Bilateral closed user group
.T&
cw(18p) | lw(120p) .
1.10 T{
Bilateral closed user group with outgoing access
T}
.T&
cw(18p) | lw(120p) .
1.11 Incoming calls barred
.T&
cw(18p) | lw(120p) .
1.12 Reverse charging acceptance
.T&
cw(18p) | lw(120p) .
1.13 Connect when free
.T&
cw(18p) | lw(120p) .
1.14 Waiting allowed
.T&
cw(18p) | lw(120p) .
1.15 Redirection of calls
.T&
cw(18p) | lw(120p) .
1.16 T{
On\(hyline facility parameter registration/cancellation
T}
.T&
cw(18p) | lw(120p) .
1.17 T{
DTE inactive registration/cancellation
T}
.T&
cw(18p) | lw(120p) .
1.18 Data and time indication
.T&
cw(18p) | lw(120p) .
1.19 Hunt group
.T&
cw(18p) | lw(120p) .
2\fB.\ \ \fR T{
Optional user facilities requested by the DTE on a per\(hycall basis
T}
.T&
cw(18p) | lw(120p) .
2.1\ Direct call
.T&
cw(18p) | lw(120p) .
2.2\ Abbreviated address calling
.T&
cw(18p) | lw(120p) .
2.3\ Multi\(hyaddress calling
.T&
cw(18p) | lw(120p) .
2.4\ Reverse charging
.T&
cw(18p) | lw(120p) .
2.5\ RPOA selection
.T&
cw(18p) | lw(120p) .
2.6\ Charging information
.T&
cw(18p) | lw(120p) .
2.7\ Called line identification
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/X.81 [T2.81], p.22\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 12/X.81, (N), p.23\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
6.2.1.2
\fITiming requirements\fR
.sp 9p
.RT
.PP
Phase and clock adjustment regulations are not applicable in the
case of non\(hyidentical data transmission rates.
.RT
.sp 1P
.LP
6.2.1.3
\fIBit rate conversion\fR
.sp 9p
.RT
.PP
For bit rate conversion between the two non\(hyidentical data
transmission services, a flow control is needed, since the effective mean
data transfer rate must be decreased to the rate of the slower terminal.
.PP
The flow control method required must be derived from the protocols
applied in both terminals.
.RT
.sp 1P
.LP
6.2.1.3.1
\fIProtocol compatible terminals\fR
.sp 9p
.RT
.PP
Assuming a HDLC\(hybased terminal to terminal protocol rate conversion
can be provided by the\ IWF by flag insertion/extraction and use of intermediate
buffer capacity:
.PP
In an existing connection, both the ISDN\(hysection and the CSPDN\(hysection
are bit\(hytransparent, but differing data signalling rates are used. It
is
assumed that both terminals are protocol\(hycompatible above the physical
layer of the reference model. Complying examples may be teletex\(hyterminals,
but also
multi\(hymode terminals, as long as they are in the same mode, e.g. in
the teletex mode. A further assumption is that the terminal\(hyto\(hyterminal
protocol includes a flow control facility, based on\ HDLC. The data transfer
is then decreased to
the capability of the slower terminal by injection of interframe time fill
flags into the\ ISDN section. The only functions related to rate conversion
to be effected by the\ IWF are to extract interframe time fill from the
ISDN/CSPDN directed data stream, to inject the necessary interframe time
fill into the
CSPDN/ISDN directed data stream, and intermediate buffering.
.PP
The IWF\(hyfunctions needed during the data transfer phase can be
restricted then to:
.RT
.LP
1)
provision of the physical layer adaptation functions by use
of suitable interface modules to access both networks,
and
.LP
2)
support of the rate conversion provided by the terminals'
flow control facility by provision of an intermediate buffer
capacity and flag extraction/insertion.
.PP
The buffer capacity must be related to the maximum frame length
and window size. In this respect, all link channel states and also exception
conditions have to be considered, including their description in\ X.25.
.PP
Figures 13/X.81 and 14/X.81 below are examples for frame sequences on both
interfaces of the\ IWF.
.RT
.sp 1P
.LP
6.2.1.3.2
\fITerminals with different protocols\fR
.sp 9p
.RT
.PP
This case requires further study.
.RT
.sp 1P
.LP
6.2.2
\fISupport of the OSI\(hynetwork layer service (OSI\(hyNLS)\fR
.sp 9p
.RT
.PP
Is as described in \(sc\ 6.1.2.
.RT
.sp 1P
.LP
6.2.3
\fISignalling conversion (protocol mapping)\fR
.sp 9p
.RT
.PP
Is for further study, considering also \(sc\ 6.1.3.
.RT
.sp 1P
.LP
6.2.4
\fIProtocol mapping for supplementary services\fR
.sp 9p
.RT
.PP
Is as described in \(sc\ 6.1.4.
.RT
.sp 1P
.LP
6.2.5
\fIMapping of service signals and causes\fR
.sp 9p
.RT
.PP
Is as described in \(sc\ 6.1.5.
.RT
.sp 2P
.LP
\fB7\fR \fBOperation and maintenance\fR
.sp 1P
.RT
.PP
Is for further study.
.bp
.RT
.LP
.rs
.sp 24P
.ad r
\fBFigure 13/X.81, (N), p.24\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 24P
.ad r
\fBFigure 14/X.81, (N), p.25\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fBRecommendation\ X.82\fR
.RT
.sp 2P
.ce 1000
\fI\fB\fR \fBDETAILED\ ARRANGEMENTS\ FOR\fR \
\fBINTERWORKING\fR
.EF '% Fascicle\ VIII.3\ \(em\ Rec.\ X.82''
.OF '''Fascicle\ VIII.3\ \(em\ Rec.\ X.82 %'
.ce 0
.sp 1P
.ce 1000
\fBBETWEEN\ CSPDNs\ AND\ PSPDNs\ BASED\ ON\ RECOMMENDATION\ T.70\fR
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that administrations are currently operating CSPDNs and PSPDNs;
.PP
(b)
that it is essential to make it possible to allow
interworking between DTEs connected to the different types of PDNs;
.PP
(c)
that CCITT services, e.g. telematic services, can be
carried by PSPDN or CSPDN or both, as defined in existing Recommendations\
T.70 and\ X.300;
.PP
(d)
that Recommendation T.70 defines the network\(hyindependent basic transport
service for telematic services;
.PP
(e)
that Recommendation X.300 defines general principles
for interworking between public networks, and between public networks and
other networks for the provision of data transmission services;
.PP
(
f
)
that Recommendation X.322 defines general
arrangements for interworking between PSPDNs and CSPDNs for the provision of
data transmission services;
.PP
(g)
that Recommendation X.75 defines procedures for
PSPDN/PSPDN interworking and that Recommendation\ X.71 defines procedures for
CSPDN/CSPDN interworking;
.PP
(h)
that Recommendation\ X.25 defines the user interface to PSPDNs, and that
Recommendations\ X.21/X.21\|\fIbis\fR define the user interface to CSPDNs;
.sp 1P
.LP
\fIunanimously declares the view\fR
.sp 9p
.RT
.PP
that detailed arrangements for interworking between CSPDNs and
PSPDNs on the basis of Recommendation\ T.70 for telematic services shall
be in accordance with the procedures specified in this Recommendation.
.sp 1P
.ce 1000
CONTENTS
.ce 0
.sp 1P
.sp 2P
.LP
0
\fIIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
1
\fIScope and field of application\fR
.sp 9p
.RT
.sp 1P
.LP
2
\fIReferences\fR
.sp 9p
.RT
.sp 1P
.LP
3
\fIDefinitions\fR
.sp 9p
.RT
.sp 1P
.LP
4
\fIAbbreviations\fR
.sp 9p
.RT
.sp 1P
.LP
5
\fIGeneral aspects\fR
.sp 9p
.RT
.LP
5.1
Circuit switched public data network
.LP
5.2
Packet switched public data network
.sp 1P
.LP
6
\fISpecification of interworking functions\fR
.sp 9p
.RT
.LP
6.1
Connection establishment phase
.LP
6.1.1
Connection establishment initiated on the CSPDN
side
.LP
6.1.2
Connection establishment initiated on the PSPDN
side
.LP
6.2
Connection release phase
.LP
6.2.1
Connection release initiated on the CSPDN
side
.LP
6.2.2
Connection release initiated on the PSPDN
side
.LP
6.2.3
Connection release initiated by the IWF T.70
.bp
.LP
6.3
Data transfer phase
.LP
6.3.1
Handling of user data
.LP
6.3.2
Handling of qualifier bit
.LP
6.3.3
Handling of delivery confirmation bit
.LP
6.3.4
Handling of more data bit
.LP
6.3.5
Reset
.sp 1P
.LP
7
\fIRestart request\fR
.sp 9p
.RT
.LP
7.1
Restart request initiated by the PSPDN
.LP
7.2
Restart request initiated by the IWF T.70
.sp 1P
.LP
\fIAppendix I\fR \ \(em\ Items in relationship to the OSI connection\(hymode
nework
service
.sp 9p
.RT
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation is one of a set of Recommendations produced to facilitate
considerations of interworking between networks. It is based on
Recommendation\ X.300, which defines the general principles for interworking
between public networks, and between public networks and other networks
for the provision of data transmission services. Recommendation\ X.300
indicates in
particular how collections of physical equipment can be represented as
\*QSubnetworks\*U for consideration in interworking situations.
.PP
This Recommendation describes the interworking arrangements between
circuit switched public data networks (CSPDN) and packet switched public
data networks (PSPDN) based on CCITT Recommendation\ T.70.
.RT
.sp 2P
.LP
\fB1\fR \fBScope and field of application\fR
.sp 1P
.RT
.PP
The purpose of this Recommendation is to describe the detailed
arrangements for the interworking between CSPDNs and PSPDNs based on
Recommendation\ T.70. These arrangements are applicable only to the interworking
involving telematic services, and not to the interworking involving
communication capabilities described in Recommendation\ X.300.
.PP
The mapping of protocol data units taken from different protocols is limited
to the capabilities of each of the protocols. The functions that are
required to provide the full OSI connection\(hymode network service (CONS)
and their relation to this Recommendation can be found in the
Appendix\ I.
.RT
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.sp 1P
.LP
Recommendation T.70
Network\(hyindependent basic transport service for
telematic services,
.sp 9p
.RT
.LP
Recommendation X.1
International user classes of service in public data
networks and integrated services digital networks
(ISDNs),
.LP
Recommendation X.2
International data transmission services and
optional user facilities in public data networks and
ISDNs,
.LP
Recommendation X.21
Interface between data terminal equipment (DTE) and
data circuit\(hyterminating equipment (DCE) for
synchronous operation on public data networks,
.LP
Recommendation X.21\|\fIbis\fR Use on public data networks of data terminal
equipment (DTE) which is designed for interfacing to
synchronous V\(hyseries modems,
.LP
Recommendation X.25
Interface between data terminal equipment (DTE) and
data circuit\(hyterminating equipment (DCE) for terminals
operating in the packet mode and connected to public
data networks by dedicated circuit,
.LP
Recommendation X.71
Decentralized terminal and transit control
signalling system on international circuits between
synchronous data networks,
.LP
Recommendation X.75
Packet switched signalling system between public
networks providing data transmission services,
.LP
Recommendation X.121
International numbering plan for public data
networks,
.LP
Recommendation X.300
General principles for interworking between public
networks, and between public networks and other
networks for the provision of data transmission
services.
.bp
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.PP
No specific definitions need to be taken into account.
.RT
.sp 2P
.LP
\fB4\fR \fBAbbreviations\fR
.sp 1P
.RT
.sp 1P
.LP
CLI
Calling Line Identification
.sp 9p
.RT
.LP
CONS
Connection\(hymode Network Service
.LP
COT
Class of Traffic
.LP
CP
Call Progress
.LP
CSPDN
Circuit Switched Public Data Network
.LP
CUG
Closed User Group
.LP
DM
Disconnected Mode
.LP
DNIC
Data Network Identification Code
.LP
DTE
Data Terminal Equipment
.LP
EOS
End of Selection
.LP
IWF
Interworking Function
.LP
NS
Network Service
.LP
OSI
Open Systems Interconnection
.LP
PDN
Public Data Networks
.LP
PSPDN
Packet Switched Public Data Network
.LP
QOS
Quality of Service
.LP
SABM
Set Asynchronous Balanced Mode
.LP
TID
Terminal Identifier
.LP
TTC
Transit Through Connect
.LP
TTD
Transit Centres Through Connected
.LP
UA
Unnumbered Acknowledgement
.LP
UC
User Class
.sp 2P
.LP
\fB5\fR \fBGeneral aspects\fR
.sp 1P
.RT
.PP
This Recommendation, in describing interworking arrangements
between two subnetworks, adheres to the general principles of
Recommendation\ X.300. The environments of these two subnetworks are described
in the following sections.
.RT
.sp 1P
.LP
5.1
\fICircuit switched public data network\fR
.sp 9p
.RT
.PP
The CSPDN provides switched data transmission services as defined in Recommendation\
X.1 and\ X.2 for the provision of data transmission services.
The transmission capability of the CSPDN may also be used for the provision
of telematic services defined in the T\(hyseries Recommendations.
.PP
\fINote\fR \ \(em\ For additional application rules for telematic services
see \(sc\ 3.3 of CCITT Recommendation\ T.70.
.RT
.sp 1P
.LP
5.2
\fIPacket switched public data network\fR
.sp 9p
.RT
.PP
The PSPDN provides packet switched data transmission services as
defined in Recommendation\ X.1 and\ X.2 for the provision of data transmission
services. The transmission capability of the PSPDN may also be used for the
provision of telematic services defined in the T\(hyseries Recommendations.
.PP
\fINote\fR \ \(em\ For additional application rules for telematic services
see \(sc\ 3.1 of CCITT Recommendation\ T.70.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 1/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB6\fR \fBSpecification of interworking functions\fR
.sp 1P
.RT
.PP
This section describes the detailed mapping for the interworking
between CSPDNs and PSPDNs based on Recommendation\ T.70.
.RT
.sp 2P
.LP
6.1
\fIConnection establishment phase\fR
.sp 1P
.RT
.sp 1P
.LP
6.1.1
\fIConnection establishment initiated on the CSPDN side\fR
.sp 9p
.RT
.PP
Figures 2/X.82 to 6/X.82 show the signalling when a terminal
connected to the CSPDN initiates a call towards a terminal in the PSPDN. The
order of events in time might be different for unrelated signals received
from the circuit and packet switched side, depending on the transmission
delays and response times in both subnetworks.
.PP
While Figure 2/X.82 represents the successful connection establishment
several possible unsuccessful call attempts are shown in figures 3/X.82
to
6/X.82.
.RT
.sp 1P
.LP
6.1.1.1
\fISelection signals\fR
.sp 9p
.RT
.PP
Any non allocated selection character shall result in the call
being cleared with a call progress signal.
.RT
.LP
1)
First class\(hyof\(hytraffic character
(1st COT)
.LP
Alternative routing allowed/not allowed is not transferred to the PSPDN.
.LP
The implementation of transit/terminal indicator Bit\ 1 is as follows:
.LP
If Bit 1 = 0 the DNIC is included in the selection
signals;
.LP
If Bit 1 = 1 the DNIC is not included in the selection
signals.
.LP
2)
First user class character (1st UC)
.LP
1st UC is only used to indicate that 2nd UC follows.
.LP
3)
Second user class character (2nd UC)
.LP
When the 2nd UC indicate TELETEX by \*Q1001\*U in the bits b1 to
b4, this shall be mapped to \*Q00000010\*U in the first octet
of the call user data field of the call request packet of
Recommendation\ X.75. In case there is no 2\ UC or in cases of
coding other than \*Q1001\*U the call attempt may either be
rejected or continued.
.LP
\fINote\fR \ \(em\ This reflects the status of Recommendation\ T.70.
However, the transparency of the call user data field needs
further consideration. Other possible mapping requirements
e.g.\ to the class of traffic facility of
Recommendation\ X.75 are for further study.
.bp
.LP
4)
Second class\(hyof\(hytraffic character
(2nd COT)
.LP
Bit b1 is used to indicate national/international traffic, and is not
to be transferred in the Recommendation\ X.75 signalling. The bits b2 and
b3 indicate whether the called line identification of the called terminal
is requested (b2) and/or the closed user group characters of the calling
terminal are following.
.LP
5)
Third class\(hyof\(hytraffic character
(3rd COT)
.LP
When receiving a 3rd COT the call attempt may either be
rejected or continued. The possible future use of the 3rd COT is for further
study.
.LP
6)
Closed user group characters
(CUG)
.LP
The closed user group characters are transferred as CUG
utility in Recommendation\ X.75. If the CUG sequence contains less than
4\ characters, excluding DNIC, zeros are inserted in the X.75 CUG utility.
If a CUG\ DNIC is not included in the X.71 signalling, a dummy DNIC of
\*Q0000\*U
is inserted in the CUG utility.
.LP
7)
Network or service identification signal
.LP
The IWF T70 shall return a DNIC.
.LP
8)
Called DTE address
.LP
The selection signals received from the CSPDN are
transferred into the X.75 address field. If the called DTE address does not
contain a DNIC, a DNIC shall be added by the IWF T.70.
.sp 1P
.LP
6.1.1.2
\fITransit through connect signal\fR \fI(TTC)\fR
.sp 9p
.RT
.PP
The Calling line identification shall always be required
(b2\ =\ 1).
.RT
.sp 1P
.LP
6.1.1.3
\fICalling line identification signal\fR \fI(CLI)\fR
.sp 9p
.RT
.PP
The calling line identification signals are used in the calling DTE address
field in the X.75 Call Request Packet. If the calling line ID does not
contain a CNIC, a DNIC may be added by the IWF T.70.
.RT
.sp 1P
.LP
6.1.1.4
\fICall progress signal\fR \fI(CP)\fR
.sp 9p
.RT
.PP
The call progress signal \*Qterminal called\*U is sent to inform the
calling terminal that the call is being established.
.PP
The IWF may repeat this CP in order to avoid that the call attempt is cleared
by the calling DTE before the call attempt in the PSPDN is either
connected or timed out and cleared.
.RT
.sp 1P
.LP
6.1.1.5
\fICall request packet\fR
.sp 9p
.RT
.LP
1)
Called and calling DTE address
.LP
The called DTE address is obtained from the DNIC and the
called terminal number in the X.71 selection signals. The end of selection
character is not transferred.
.LP
The calling DTE address is obtained from the X.71 calling
line identification signals. If no DNIC is included, the DNIC of the calling
network will be inserted.
.LP
2)
Network utilities\fR
.LP
The throughput class indication shall be signalled and the value indicated
shall be mapped to the bit rate on the circuit switched side. A lower throughput
class in the call connected packet may be accepted.
.LP
The default value of 2 for window size, and 128 for packet size, shall
apply for all calls and needs therefore not be signalled. The use of other
values is subject to bilateral agreement.
.LP
3)
User facilities
.LP
No user facilities shall be signalled.
.LP
4)
Call user data
.LP
See \(sc\ 6.1.1.1, item 3).
.sp 1P
.LP
6.1.1.6
\fISABM command\fR
.sp 9p
.RT
.PP
The calling terminal uses address (B) in commands and (A) in
responses, the IWF T.70 uses address (A) in commands and (B) in responses
according to Recommendation\ T.70.
.PP
After receiving the originating through connection signal the IWF T.70
shall wait for the link set up by the DTE connected to the CSPDN. After
a
time\(hyout condition the IWF T.70 may attempt to set up the link level
itself.
.bp
.RT
.LP
.rs
.sp 27P
.ad r
\fBFigure 2/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 20P
.ad r
\fBFigure 3/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 21P
.ad r
\fBFigure 4/X.82, (N), p.29\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 25P
.ad r
\fBFigure 5/X.82, (N), p.30\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 20P
.ad r
\fBFigure 6/X.82, (N), p.31\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.1.2
\fIConnection establishment initiated on the PSPDN side\fR
.sp 9p
.RT
.PP
Figures 7/X.82 to 11/X.82 show the signalling when a terminal
connected to the PSPDN initiates a call towards a terminal in the CSPDN. The
order of events in time might be different for unrelated signals received
from the circuit and packet switched side, depending on the transmission
delays and response times in both subnetworks.
.PP
While Figure\ 7/X.82 represents the successful connection
establishment
several possible unsuccessful call attempts are shown in Figures\ 8/X.82
to\ 11/X.82.
.RT
.sp 1P
.LP
6.1.2.1
\fICall request packet\fR
.sp 9p
.RT
.PP
The called DTE address always includes a DNIC which may be
transferred to the CSPDN.
.PP
The calling DTE address is stored and will be transferred later
in the calling line identification signal, if requested by the called
DTE.
.RT
.LP
1)
Network utilities
.LP
The transit network identification code shall not be
transferred in the X.71 signalling, since DNICs cannot be signalled in
X.71 in the forward direction.
.LP
The call identifier shall not be signalled in X.71.
.LP
If the received throughput class indication is greater than the data
signalling on the circuit switched side, the value of the data
signalling rate shall be returned. In all other cases the received value is
returned.
.LP
The default values of 2 for window size, and 128 for packet size, shall
apply for all calls. The use of other values is subject to
bilateral agreement.
.LP
According to Recommendation T.70 terminals shall not use the fast select
facility. the receipt of fast select
indication shall result in
sending a clear request packet.
.LP
The closed user group and closed user group with outgoing
access are mapped to the corresponding signals in
Recommendation\ X.71.
.LP
The transit delay indication cannot be signalled in
Recommendation\ X.71.
.bp
.LP
2)
User facilities
.LP
For further study.
.LP
3)
Call user data
.LP
The telematic protocol identifier as defined in
Recommendation\ T.70 is mapped to the 2nd UC in Recommendation\ X.71 (all
remaining information will get lost). When receiving other codes in the
first octet of the call user data field of the call request packet of
Recommendation\ X.75 the call attempt may either be rejected or
continued.
.LP
\fINote\fR \ \(em\ This reflects the status of Recommendation\ T.70.
However, the transparency of the call user data field needs further
consideration. Other possible mapping requirements e.g.\ to the class of
traffic facility of Recommendation\ X.75 are for further study.
.sp 1P
.LP
6.1.2.2
\fISelection signals\fR
.sp 9p
.RT
.LP
1)
First class\(hyof\(hytraffic character (1st COT)
.LP
\*QAlternative routing allowed\*U is signalled. The X.75
called DTE address may be passed unchanged to the CSPDN or the DNIC may
be stripped.
.LP
\fINote\fR \ \(em\ The X.75 addresses of the called and calling DTE
always include a DNIC.
.LP
Bit 1 is set accordingly. Bit 1 = 0: DNIC included;
Bit\ 1=\ 1: DNIC not included. \*QUC follows\*U is indicated.
.LP
2)
First user class character (1st UC)
.LP
1st UC is only used to indicate that the second
class\(hyof\(hytraffic (2nd COT) character and second user class (2nd UC)
character follows.
.LP
3)
Second user class character (2nd UC)
.LP
When the first octet of the call user data field of the
call request packet of Recommendation\ X.75 indicates Teletex by \*Q00000010\*U,
this shall be mapped to \*Q1001\*U in the bits b1 to b4 of the 2nd UC in
Recommendation\ X.71. In cases of coding other than \*Q00000010\*U the
call attempt may either be rejected or continued.
.LP
\fINote\fR \ \(em\ This reflects the status of Recommendation\ T.70.
However, the transparency of the call user data field needs further
consideration. Other possible mapping requirements e.g.\ to the class of
traffic facility of Recommendation\ X.75 are for further study.
.LP
4)
Second class\(hyof\(hytraffic (2nd COT)
.LP
Bits 1, 2 and 4 of the 2nd COT are always set to \*Q0\*U.
Bit 3 is set according to the X.75 utilities received.
.LP
5)
Third class\(hyof\(hytraffic character (3rd COT)
.LP
The third class\(hyof\(hytraffic character is not transmitted by the
IWF\ T.70.
.LP
6)
Closed user group (CUG)
.LP
See \(sc\ 6.1.1.1, item 6).
.LP
7)
Transit through connect signal (TTC)
.LP
The calling line identification is only signalled if it has been requested
in the TTC signal. The transit centres through\(hyconnected (TTD) signal
is sent in other cases.
.sp 1P
.LP
6.1.2.3
\fISABM command\fR
.sp 9p
.RT
.PP
The calling DTE uses address (B) in commands and (A) in responses, the
called DTE uses address (A) in commands and (B) in responses, according
to CCITT Recommendation\ T.70.
.RT
.sp 1P
.LP
6.1.2.4
\fICall connected packet\fR
.sp 9p
.RT
.PP
If any network or service identification signals are received that indicate
transit networks, these are transferred in the Transit network
identification network utility. The Throughput class is set according to the
procedure described under \*QNetwork utilities\*U (see \(sc\ 6.1.2.1, item\
1)).
.PP
The time relation between \*QUA Response Frame\*U received and \*QCall
Connected Packet\*U sent is for further study.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 7/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 25P
.ad r
\fBFigure 8/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 16P
.ad r
\fBFigure 9/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 10/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 11/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
6.2
\fIConnection release phase\fR
.sp 1P
.RT
.sp 1P
.LP
6.2.1
\fIConnection release initiated on the CSPDN\(hyside\fR \| (Figure 12/X.82)
.sp 9p
.RT
.LP
.rs
.sp 50P
.ad r
\fBFigure 12/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
6.2.2
\fIConnection release initiated on the PSPDN\(hyside\fR \|
(Figure 13/X.82)
.sp 9p
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 13/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
6.2.3
\fIConnection release initiated by the IWF T70\fR \|
(Figure 14/X.82)
.sp 9p
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 14/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
6.3
\fIData transfer phase\fR
.sp 1P
.RT
.sp 1P
.LP
6.3.1
\fIHandling of user data\fR
.sp 9p
.RT
.PP
The user data shall be transferred transparently from the user data field
in the data packet on the packet switched side to the user data field in
the network data block on the circuit switched side, and vice versa (see
Figure\ 15/X.82).
.RT
.LP
.rs
.sp 26P
.ad r
\fBFigure 15/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.3.2
\fIHandling of\fR
\fIQualifier bit\fR \fI(Q\(hybit)\fR
.sp 9p
.RT
.PP
Independent from the value of the Q\(hyBit in an incoming data packet
the IWF T.70 may
.RT
.LP
a)
use Q\(hybit = 0 in the corresponding outgoing network data
block, and vice versa;
.LP
b)
transfer it transparently. This means that the value of the Q\(hybit
in an incoming data packet shall be transferred in the corresponding
outgoing network data block, and vice versa.
.sp 1P
.LP
6.3.3
\fIHandling of Delivery confirmation bit (D\(hybit)\fR
.sp 9p
.RT
.PP
The D\(hybit in incoming Data Packets is ignored. The IWF T70 shall
set the D\(hybit\ =\ 0 in outgoing Data Packets.
.RT
.sp 1P
.LP
6.3.4
\fIHandling of\fR
\fIMore data bit\fR \fI(M\(hybit)\fR
.sp 9p
.RT
.PP
Network Data Blocks with more than 128 octets (up to 2048) are
segmented into a Data Packet sequence with a number of octets in each Data
Packet according to the selected value for the packet size. If the received
M\(hybit of the last Data Packet in the sequence is set to\ 0. In all other
cases the M\(hybit\ =\ 1.
.PP
Received Data Packets may be directly transferred in Network Data
Blocks of the same size with the M\(hybit unchanged and transferred as
one Network Data Block.
.bp
.RT
.sp 1P
.LP
6.3.5
\fIReset\fR
.sp 9p
.RT
.PP
When a Reset request is received from the packet switched side this shall
result in a disconnection of the link on the circuit switched side. After
successful disconnection and setting up of the link again the reset is
confirmed. The procedure is shown in Figure\ 16/X.82.
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 16/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB7\fR \fBRestart request\fR
.sp 1P
.RT
.sp 1P
.LP
7.1
\fIRestart request initiated by the PSPDN\fR
.sp 9p
.RT
.PP
An incoming Restart request packet from the packet switched side
results in a clearing of all related circuits on the circuit switched side.
This is described in Figure\ 17/X.82.
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 17/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
7.2
\fIRestart request iniciated by the IWF T.70\fR
.sp 9p
.RT
.PP
The IWF T.70 may request a restart by clearing all circuit on the circuit
switched side and sending Restart request on the packet switched side.
This is shown in Figure 18/X.82.
.RT
.LP
.rs
.sp 23P
.ad r
\fBFigure 18/X.82, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation X.82)
.sp 9p
.RT
.ce 0
.ce 1000
\fBItems in relationship to the OSI connection\(hymode network service\fR
.sp 1P
.RT
.ce 0
.LP
1)
Connection establishment phase
.sp 1P
.RT
.LP
\fR \(em
Network address extension
not
supported
.LP
\(em
Receipt confirmation selection
not supported
(see Note\ 1)
.LP
\(em
Expedited data
not supported (see
Note\ 1)
.LP
\(em
QOS
not supported (see Note 1)
.LP
\(em
NS user data
not supported (see Note 2)
.LP
2)
Data transfer phase
.LP
\(em
D\(hybit
not supported (see Note 1)
.LP
3)
Connection release phase
.LP
\(em
Network address extension
not
supported,
.LP
\fR
\(em
NS user data
not supported (see
Note\ 2).
.bp
.LP
\fINote\ 1\fR \ \(em\ NS provider options, when provided within a
subnetwork, would lead to additional actions and events
(i.e.\ receipt confirmation, EXPEDITED DATA transfer).
.LP
\fINote\ 2\fR \ \(em\ The objective is to make this parameter a mandatory
parameter to be supported by all subnetworks in the future. However, a
number of existing subnetworks cannot support it now. During the
interim period, while these subnetworks exist and are not modified to
provide this parameter, it is considered as a provider\(hyoption. No
negotiation mechanism is needed in the connection\(hymode network
service. Limiting, in some subnetworks, the length of NS\(hyuser\(hydata to
be provided to a value lower than 128\ octets (e.g.\ 16 to\ 32\ octets)
for an interim period would imply fewer changes to existing
interfaces and signalling systems and would simplify the introduction
of such a service in existing subnetworks.
.LP
.rs
.sp 43P
.ad r
\fBBlanc\fR
.ad b
.RT
.LP
.bp